1. Field of the Invention
The present invention relates generally to cloud computing, and in particular, to a method, apparatus, and article of manufacture for a file format that enables cloud computing with both low data space and low bandwidth consumption.
2. Description of the Related Art
Computing at/in the cloud can be very data intensive. Assets used during computation must be present on the computers where computation is performed. In many cases, these assets are present on a user client machine, and have to be packaged and sent to one or more locations in the cloud. Over time, various problems occur. One problem is that very large amounts of data bandwidth are required to send this data into a permanent storage location in the cloud, and additionally to send that data to the computing machines when it is required for computation. A second problem is the size of data stored on the cloud. Over time, this data may include many duplicates wasting precious space. A third problem is that standard assets uploaded for prior computation cannot be easily “upgraded” when improvements to those standard assets are available. To better understand the problems of the prior art, a description of assets and cloud computing may be useful.
As used herein, an asset refers to an object, shape, image, video clip, media content, audio clip, audio-video clip, etc. Assets are commonly used in a variety of applications including image processing and video editing systems. When editing graphics, etc. a scene graph is commonly utilized. In this regard, a scene graph is typically used for 2D and/or 3D graphics image synthesis (e.g., rendering—either offline high-quality rendering, or fast interactive rendering for real-time scene editing, walkthroughs, animation generation, and games). A scene graph is a general data structure that arranges the logical and often (but not necessarily) spatial representation of a graphical scene. A scene graph is often a collection of nodes in a graph. A node may have many children and also multiple parents, with the effect of a parent applied to all its child nodes. In the context of scene graphs, the graphs may be directed acyclic graphs (DAGs). In a DAG, when a graph edge is followed, the edge only goes one direction, and a traversal can follow any number of edges and never reach the current node again (acyclic).
In a scene graph (also referred to as a process graph/tree), a root node defines a rendering of a particular view of a scene. For a given scene, there may be hundreds of views—which is equivalent to hundreds of root nodes. For example, there may exist a hundred scene graphs of the same box with each scene graph presenting a different view of the box (e.g., different angles or objects [e.g., a ball] inside of the box). Each root node defines everything that would be seen once the scene graph is fully processed.
To process a scene graph (i.e., to render a scene), the graph is traversed (e.g., beginning with the root node and traversing each child node). To improve the rendering time, it may be desirable to perform all or some parts of the rendering using multiple computers/processors available in the cloud (referred to as compute nodes). Thus, with cloud computing, the rendering is not being performed locally where the data originates from. Consequently, the data/assets need to be transmitted/uploaded from the client to the compute node where the rendering is performed. However, the translation and serialization of all assets every time is expensive (both in terms of computation and infrastructure). Further, bandwidth requirements may be prohibitively high for all the data to be transmitted to the cloud. Thus, it is undesirable to rely on data transmitted from a client (e.g., due to limited bandwidth, processing capabilities, infrastructure, etc.).
In addition, because users may re-render data from the cloud, the data may be reused, so it must be stored at the cloud. Storing all of the data in the cloud is expensive (in terms of processing and infrastructure required). Further, over time, some data may be duplicated millions of times in storage. Also, even if stored in the cloud, the data must again be transferred from cloud storage to compute nodes, requiring even more bandwidth. At the renderer, the same data (e.g., texture, mesh, etc.) may be read multiple times, and multiple copies may persist throughout rendering, requiring more memory.
In view of the above, it is desirable to attempt to reduce the amount of data that is stored as well as to reduce the amount of data that needs to be transferred to the compute node.